10.1 무한 문맥(Infinite Context) 에이전트와 RAG의 대체 가능성

1. 서론: 인지적 지평의 확장과 문맥의 경제학

인공지능, 특히 대규모 언어 모델(Large Language Model, LLM)의 진화 과정에서 ’문맥(Context)’의 길이는 모델의 지능적 한계를 규정하는 가장 결정적인 물리적 제약이자, 동시에 인지적 지평을 확장하려는 연구자들의 주된 전장이었다. 초기 BERT 모델이 512 토큰이라는 협소한 윈도우(Context Window)에 갇혀 문장 단위의 이해에 머물렀던 반면, 2024년과 2025년을 기점으로 등장한 모델들은 수십만에서 수백만, 심지어 이론적으로 ’무한(Infinite)’에 가까운 문맥을 처리할 수 있다고 주장하고 있다. 이러한 기술적 도약은 단순히 더 긴 텍스트를 읽을 수 있다는 차원을 넘어, 에이전트가 단기적인 작업 수행자를 벗어나 장기적인 기억(Long-term Memory)을 보유하고 복잡한 서사를 관통하는 추론을 수행할 수 있는 ’연속적인 인격체’로 진화할 수 있는 가능성을 시사한다.1

전통적인 트랜스포머(Transformer) 아키텍처가 지배하던 지난 수년간, 긴 문맥 처리에 수반되는 이차 함수적(Quadratic) 연산 비용과 메모리 병목 현상은 넘을 수 없는 벽으로 여겨졌다. 이에 대한 현실적이고 효율적인 대안으로 등장한 것이 바로 검색 증강 생성(Retrieval-Augmented Generation, RAG)이다. RAG는 모델 내부의 제한된 문맥 윈도우를 우회하기 위해 외부의 벡터 데이터베이스(Vector Database)를 활용, 필요한 정보만을 선별적으로 검색하여 프롬프트에 주입하는 방식으로 LLM의 기억 용량을 사실상 무한대로 확장하는 역할을 수행해 왔다.3 RAG는 환각(Hallucination)을 줄이고 최신 정보를 반영할 수 있다는 강력한 장점을 바탕으로 엔터프라이즈 AI 시스템의 표준 아키텍처로 자리 잡았다.

그러나 최근 Mamba, Jamba, 그리고 Google의 Titans와 같은 차세대 아키텍처들은 선형적(Linear) 확장성과 신경 메모리(Neural Memory) 기술을 무기로, RAG와 같은 외부 보조 장치 없이도 모델 자체가 방대한 정보를 직접 소화하고 기억할 수 있는 시대를 예고하고 있다.5 이는 근본적인 질문을 던진다. 모델이 수백만 개의 문서를 한 번에 입력받아 전체적인 맥락 속에서 정보를 처리할 수 있다면, 파편화된 정보를 검색하여 짜맞추는 RAG 파이프라인은 과연 존속할 가치가 있는가? ’무한 문맥 에이전트’는 RAG를 구시대의 유물로 만들 것인가, 아니면 경제성과 정확성이라는 현실적 장벽 앞에서 상호 보완적인 공존을 택할 것인가?

본 장에서는 ’무한 문맥’을 구현하기 위한 최신 아키텍처의 기술적 메커니즘을 심도 있게 분석하고, 이를 RAG 시스템과 성능, 경제성, 인프라 효율성 측면에서 다각도로 비교한다. 특히 단순한 기술적 나열을 넘어, 각 접근 방식이 에이전트의 추론 능력과 기억 형성 과정에 미치는 영향을 분석함으로써, 차세대 AI 시스템 설계에 있어 RAG와 무한 문맥 기술의 대체 가능성과 융합의 미래를 전망한다.

2. 무한 문맥 구현을 위한 아키텍처의 진화: 트랜스포머를 넘어서

무한 문맥 에이전트의 실현 가능성을 논하기 위해서는 먼저 트랜스포머가 가진 구조적 한계와 이를 극복하기 위해 등장한 상태 공간 모델(State Space Models, SSM) 및 신경 메모리 아키텍처의 혁신적인 메커니즘을 이해해야 한다.

2.1 트랜스포머의 이차 함수적 병목(Quadratic Bottleneck)과 KV 캐시

트랜스포머 아키텍처의 핵심인 ‘어텐션(Attention)’ 메커니즘은 입력 시퀀스 내의 모든 토큰이 서로 다른 모든 토큰과의 관계를 계산하는 구조를 가진다. 입력 시퀀스의 길이가 N일 때, 어텐션 연산의 계산 복잡도는 O(N^2)로 증가하며, 이는 문맥 길이가 길어질수록 기하급수적인 연산량을 요구하게 됨을 의미한다.7

더욱 치명적인 문제는 추론(Inference) 단계에서의 메모리 사용량이다. 모델이 다음 토큰을 생성할 때마다 이전의 모든 토큰에 대한 Key(K)와 Value(V) 상태를 저장해야 하는데, 이 ’KV 캐시(KV Cache)’의 크기는 시퀀스 길이에 비례하여 선형적으로 증가한다. 100만 토큰(1M) 수준의 문맥을 처리하려면 수백 기가바이트(GB)에서 테라바이트(TB) 단위의 GPU 메모리(VRAM)가 필요하게 되며, 이는 단일 GPU는 물론 고성능 클러스터에서도 감당하기 어려운 자원 소모를 초래한다.1

또한, 트랜스포머는 문맥 윈도우가 아무리 길어도 ‘Lost in the Middle’ 현상, 즉 문맥의 중간 부분에 위치한 정보를 효과적으로 기억하거나 활용하지 못하는 집중력 저하 문제를 보인다. 이는 단순히 입력 가능한 토큰 수를 늘리는 것만으로는 진정한 의미의 긴 문맥 이해를 달성할 수 없음을 시사한다.9

2.2 Mamba와 SSM: 선형 복잡도의 혁명과 선택적 스캔

이러한 트랜스포머의 한계를 타파하기 위해 등장한 Mamba 아키텍처는 구조화된 상태 공간 모델(Structured State Space Model, SSM)을 기반으로 한다. Mamba는 순환 신경망(RNN)의 특성을 현대적으로 재해석하여, 모든 과거 정보를 고정된 크기의 ’숨겨진 상태(Hidden State)’로 압축하여 전달한다.

• 선형 시간 복잡도 (O(N)): Mamba는 어텐션 메커니즘을 제거하고 재귀적(Recurrent) 상태 업데이트 방식을 채택함으로써, 입력 시퀀스 길이에 대해 선형적인 시간 복잡도를 달성했다. 이는 문맥 길이가 1만 토큰이든 100만 토큰이든, 토큰 하나를 생성하는 데 드는 비용이 일정함을 의미한다.10
• 선택적 스캔(Selective Scan) 알고리즘: 기존의 선형 시불변(LTI) SSM 시스템은 입력 데이터의 내용과 관계없이 동일한 방식으로 정보를 처리하여 복잡한 언어 패턴을 학습하는 데 한계가 있었다. Mamba는 입력 데이터에 따라 상태 전이 파라미터를 동적으로 조정하는 ‘선택적 스캔’ 메커니즘을 도입했다. 이를 통해 모델은 중요한 정보는 장기 기억에 남기고, 불필요한 정보(노이즈)는 즉시 망각하는 필터링 능력을 갖추게 되었다.12
• 하드웨어 최적화: Mamba는 GPU의 메모리 계층 구조(HBM과 SRAM) 간의 데이터 이동을 최소화하는 하드웨어 인식(Hardware-aware) 알고리즘을 구현했다. 커널 퓨전(Kernel Fusion)과 병렬 스캔(Parallel Scan) 기술을 통해 트랜스포머 대비 최대 5배 빠른 훈련 및 추론 속도를 제공한다.2

2.3 상태 붕괴(State Collapse)와 정보 압축의 한계

Mamba의 효율성은 ’정보 압축’에서 온다. 그러나 “유한한 상태(Finite State)는 d차원으로 압축할 수 있는 것보다 더 많은 정보를 담을 수 없다“는 정보 이론적 한계는 여전히 존재한다.1 최근 발표된 “Stuffed Mamba” 연구는 Mamba와 같은 RNN 기반 모델이 훈련된 문맥 길이보다 훨씬 긴 시퀀스를 처리할 때 ‘상태 붕괴(State Collapse)’ 현상을 겪는다는 것을 규명했다.15

연구에 따르면, 모델의 상태 용량(State Capacity)에 비해 훈련 시퀀스가 충분히 길지 않으면, 모델은 오래된 정보를 ’망각(Forgetting)’하는 법을 제대로 배우지 못한다. 결과적으로 문맥이 길어질수록 상태 벡터가 포화(Saturated)되어 새로운 정보를 받아들이지 못하거나, 과거의 중요한 정보를 덮어쓰게 되어 정보 회수(Recall) 능력이 급격히 저하된다. 이는 Mamba 단독으로는 진정한 의미의 ’무한 문맥’을 달성하기 어려울 수 있음을 시사하며, 하이브리드 아키텍처의 필요성을 역설한다.16

2.4 하이브리드 아키텍처의 대두: Jamba와 Granite 4.0

순수 SSM의 한계인 ‘정밀한 회상(Recall)’ 능력 부족과 트랜스포머의 ‘고비용’ 문제를 동시에 해결하기 위해, 두 아키텍처를 결합한 하이브리드 모델이 2024년 이후 주류로 부상했다.

Jamba (AI21 Labs):

Jamba는 트랜스포머 레이어와 Mamba 레이어를 결합한 하이브리드 구조를 채택했다. 구체적으로는 Mamba 레이어 7개당 트랜스포머(어텐션) 레이어 1개를 배치하는 1:7 비율을 사용하여, Mamba의 효율성을 유지하면서도 어텐션의 정밀한 정보 추출 능력을 보존했다.

• MoE (Mixture-of-Experts): Jamba는 총 52B 파라미터를 가지지만, 추론 시에는 토큰당 12B 파라미터만을 사용하는 MoE 방식을 도입했다. 이를 통해 단일 80GB GPU(A100/H100)에서도 256K 길이의 문맥을 처리할 수 있는 높은 메모리 효율성을 달성했다.6
• 성능: Jamba는 이러한 하이브리드 설계를 통해 ‘Needle in a Haystack’ 테스트에서 우수한 성과를 보였으며, 순수 트랜스포머 모델 대비 3배 높은 처리량(Throughput)을 기록했다.8

IBM Granite 4.0:

IBM의 Granite 4.0 역시 Mamba-2 아키텍처와 트랜스포머, 그리고 MoE를 결합한 형태다.

• NoPE (No Positional Encoding): Granite 4.0은 위치 인코딩(Positional Encoding)을 완전히 제거하는 설계를 채택했다. 이는 모델이 훈련 때 보지 못한 길이의 문맥에서도 일반화(Generalization) 성능을 유지하도록 돕는다.18
• 기업용 효율성: Granite 4.0은 기업 환경에서의 RAG 및 긴 문맥 처리를 목표로 설계되었으며, 순수 트랜스포머 대비 70% 낮은 메모리 점유율을 통해 엣지 디바이스나 비용 효율적인 서버 환경에서의 배포를 용이하게 한다.18

2.5 Google Titans와 신경 메모리(Neural Memory): 무한을 향한 도약

가장 최근인 2024년 말 등장한 Google의 Titans 아키텍처는 기존의 ‘고정 상태’ 개념을 넘어 ’테스트 타임 학습(Test-Time Training)’이라는 새로운 패러다임을 통해 진정한 무한 문맥에 도전한다.

• 신경 장기 기억(Neural Long-Term Memory): Titans는 과거의 정보를 고정된 크기의 벡터가 아닌, 다층 퍼셉트론(MLP)과 같은 심층 신경망의 파라미터(가중치) 자체에 인코딩한다. 즉, 모델이 추론을 수행하는 동안 실시간으로 자신의 기억 모듈을 학습(Update)시킨다. 이는 단순한 압축이 아니라 정보의 추상화와 저장을 동시에 수행하는 과정이다.5
• 놀라움(Surprise) 기반 기억 형성: Titans는 입력 데이터가 예측과 얼마나 다른지를 나타내는 ‘놀라움(Surprise)’ 지표(그래디언트)를 활용한다. 예상치 못한 정보일수록 더 강한 신호를 발생시켜 장기 기억에 확실히 각인시키고, 반복적이거나 뻔한 정보는 기억 용량을 차지하지 않도록 망각 게이트(Forgetting Gate)를 통해 조절한다.5
• 초장문 처리 능력: 이러한 메커니즘을 통해 Titans는 200만 토큰(2M+) 이상의 문맥에서도 기존 트랜스포머나 Mamba보다 높은 정확도를 유지하며, 정보의 손실 없는 사실상의 무한 문맥 처리를 실현했다.22

3. RAG의 생존 논리: 단순 검색을 넘어선 인지적 보철

무한 문맥 모델들의 눈부신 기술적 진보에도 불구하고, RAG 시스템이 여전히 유효하며 오히려 진화하고 있는 이유는 명확하다. 그것은 ‘경제성’, ‘최신성’, ‘제어 가능성’, 그리고 ’검증 가능성’이라는 실용적인 가치 때문이다.

3.1 RAG의 경제학: 1M 토큰 비용 대 벡터 검색 비용

기술적으로 100만 토큰을 입력할 수 있다는 것이 매 요청마다 100만 토큰을 입력해야 함을 정당화하지는 않는다. 기업용 AI 시스템에서 비용은 가장 중요한 고려 사항 중 하나다.

비용 구조의 비대칭성:

• Infinite Context: 2025년 기준, GPT-4o나 Claude 3.5 Sonnet 수준의 고성능 모델에 100만 토큰을 입력하는 비용은 요청당 수십 달러(10~40)에 달할 수 있다. 입력 토큰(Input Token) 가격이 지속적으로 하락하고 있다 하더라도, 매 턴마다 방대한 문맥을 다시 처리해야 하는 비효율성은 사라지지 않는다.23
• RAG: 반면, 벡터 데이터베이스에서 관련성 높은 청크(Chunk) 2,000~4,000개를 검색하여 입력하는 비용은 1센트 미만이다. Elastic의 실험 결과에 따르면, RAG 방식은 전체 문맥을 입력하는 방식 대비 평균 비용이 약 1,250배 저렴한 것으로 나타났다.25

“Hidden Cost of Hello”:

사용자가 단순히 “안녕“이라고 인사하거나 “지난주 회의 요약해줘“와 같은 간단한 질문을 던질 때, 에이전트가 수천 개의 프로젝트 문서를 모두 메모리에 로드하고 있다면 이는 엄청난 자원 낭비다. 모든 상호작용에 전체 문맥을 동반하는 것은 컴퓨팅 파워의 오남용이며, 이는 서비스의 수익성을 심각하게 저해한다.26

3.2 정확성과 환각(Hallucination) 제어

긴 문맥 모델은 많은 정보를 볼 수 있지만, 그만큼 정보의 ’노이즈’에 취약해진다.

• 정보 밀도와 정확도: RAG 시스템은 검색(Retrieval) 단계에서 불필요한 정보(Distractors)를 1차적으로 필터링하므로, LLM이 처리해야 할 정보의 밀도(Density)를 높여준다. 이는 모델이 정답에 집중하게 하여 환각을 줄이는 데 기여한다. 반면, 긴 문맥 모델은 문맥 내에 상충되는 정보가 있거나 관련 없는 내용이 섞여 있을 때 혼란을 겪을 가능성이 크다.27
• 문맥 내 학습(ICL)의 한계: “Stuffed Mamba” 연구에서 밝혀진 바와 같이, 모델의 상태 용량 한계로 인해 문맥이 길어질수록 초반부의 정보가 소실되거나 왜곡될 수 있다. RAG는 정보를 외부 저장소에 ’물리적’으로 보존하므로, 모델 내부의 기억 용량 한계나 망각 문제로부터 자유롭다.15

3.3 데이터의 동적 갱신(Dynamic Updates)과 최신성

무한 문맥 모델이라 할지라도, 새로운 지식을 학습하려면 문맥을 다시 입력하거나(In-Context Learning), 모델 자체를 미세 조정(Fine-tuning)해야 한다. 이는 시간과 비용이 많이 드는 작업이다.

반면, RAG 시스템에서는 벡터 데이터베이스에 새로운 문서를 추가(Insert)하거나 수정(Update)하는 것만으로 지식 갱신이 즉시 완료된다. 주가 정보, 속보, 기업 내부 규정 변경 등 실시간으로 변하는 데이터를 다루는 에이전트에게 RAG는 대체 불가능한 민첩성을 제공한다. 100만 토큰 모델이 어제의 뉴스까지 기억할 수 있다면, RAG 에이전트는 1초 전의 뉴스까지 반영할 수 있다.30

4. 벤치마크 전쟁: 바늘, 건초더미, 그리고 추론의 깊이

’무한 문맥’과 RAG의 성능을 비교하기 위해 학계와 산업계에서는 다양한 벤치마크를 활용하고 있다. 가장 대표적인 것이 ’Needle in a Haystack(NIAH)’이지만, 최근에는 이를 넘어선 복합 추론 능력을 측정하려는 시도가 이어지고 있다.

4.1 모델별 NIAH 성능 비교

’Needle in a Haystack’은 방대한 텍스트(건초더미) 속에 숨겨진 특정 정보(바늘)를 모델이 정확히 찾아낼 수 있는지를 평가한다.

4.2 NIAH의 한계와 실제 추론(Reasoning) 능력

그러나 NIAH 벤치마크는 단순한 ‘정보 검색’ 능력을 측정할 뿐, 흩어진 정보를 조합하여 결론을 도출하는 ‘추론(Reasoning)’ 능력을 대변하지는 못한다.

• 다중 호핑 추론(Multi-hop Reasoning): “A 문서는 B 사건을 언급하고, C 문서는 B 사건의 결과를 설명한다. A와 C를 종합했을 때 최종 결론은?“과 같은 작업에서 긴 문맥 모델들은 여전히 고전하고 있다. RULER나 BABILong 벤치마크 결과에 따르면, 문맥이 길어질수록, 그리고 찾아야 할 단서(Needle)가 여러 개일수록 정확도는 급격히 하락한다.9
• RAG의 실패와 성공: BABILong 벤치마크에서 일반적인 청크 기반 RAG는 문맥이 파편화되어 있어 상호 연결된 사실(Interconnected facts)을 추론하는 데 실패했다. 반면, RMT(Recurrent Memory Transformer)나 미세 조정된 Mamba 모델은 전체 문맥을 연속적으로 처리할 수 있어 이러한 작업에서 가능성을 보였다. 이는 RAG가 ’단순 사실 검색’에는 강하지만 ’전체적인 서사 이해’에는 구조적 약점이 있음을 시사한다.9

5. 경제성 및 인프라: 토큰 비용과 지연 시간의 함수

기술적 성능을 넘어, 실제 비즈니스 환경에서의 도입 여부는 비용과 속도에 의해 결정된다.

5.1 비용 효율성 분석 (Cost Efficiency)

다음은 100만 건의 사용자 요청을 처리한다고 가정했을 때의 비용 모델링 비교다.

5.2 지연 시간(Latency)과 사용자 경험

• Prefill Time: 100만 토큰을 처리하는 데 걸리는 시간(Prefill Time)은 Mamba와 같은 선형 모델이라 하더라도 물리적인 데이터 전송 및 처리 시간을 요구한다. 사용자는 질문을 입력하고 답변이 시작될 때까지 수 초에서 수십 초를 기다려야 할 수 있다.
• Retrieval Latency: 반면 RAG는 고도로 최적화된 검색 엔진을 통해 밀리초(ms) 단위로 문서를 찾고, LLM은 짧은 텍스트만 생성하면 되므로 응답 속도(Time to First Token) 면에서 압도적으로 유리하다. LightOn의 연구에 따르면 RAG는 롱 컨텍스트 모델 대비 약 2배 빠른 지연 시간을 제공하며, 이는 실시간 챗봇 서비스에서 결정적인 차이를 만든다.31

5.3 인프라 및 하드웨어 요구사항

• 메모리 발자국: Jamba와 Granite 4.0은 Mamba 레이어와 MoE를 도입하여 KV 캐시 크기를 1/8 수준으로 줄였지만, 여전히 100만 토큰 이상의 문맥을 처리하려면 고성능 GPU(H100 등)가 필수적이다.37
• 온디바이스 AI: 스마트폰이나 엣지 디바이스와 같이 메모리가 제한된 환경(8GB~16GB RAM)에서는 거대한 문맥을 메모리에 올리는 것이 불가능하다. 이러한 환경에서는 작은 모델에 RAG를 결합하여 필요한 정보만 로드하는 방식이 유일한 현실적 대안이다.18

6. 결론: 상호 보완적 공존과 하이브리드 인텔리전스

지금까지의 분석을 종합해 볼 때, ’무한 문맥 에이전트’가 RAG를 완전히 대체하여 RAG 기술을 사장시킬 것이라는 전망은 시기상조이며 현실적이지 않다. 오히려 두 기술은 서로의 단점을 상쇄하고 장점을 극대화하는 방향으로 융합될 것이다.

6.1 대체 불가능한 영역의 존재

1. 초저지연/저비용 검색: 단순 사실 확인이나 특정 데이터 조회와 같이 전체 문맥 이해가 필요 없는 작업에서는 RAG의 경제성과 속도를 따라올 수 없다.
2. 실시간성: 뉴스, 금융 데이터 등 초 단위로 변하는 정보를 다루는 에이전트에게 RAG(또는 Web Search)는 필수불가결하다.
3. 심층 추론 및 서사 이해: 반면, 소설 분석, 법률 판례의 흐름 파악, 긴 코드 베이스의 리팩토링과 같이 파편화된 정보(Chunk)로는 파악할 수 없는 전체적인 맥락과 인과관계를 이해해야 하는 작업에서는 무한 문맥 모델이 RAG를 압도한다.

6.2 미래의 에이전트 아키텍처: 공존 (Symbiosis)

결국 미래의 AI 에이전트는 RAG와 무한 문맥 모델의 하이브리드 결합으로 진화할 것이다.

• Coarse-grained RAG (거친 입자 검색): 기존 RAG가 문장이나 문단 단위의 미세한 청크를 검색했다면, 앞으로는 책 한 챕터나 전체 문서(수만 토큰)를 통째로 검색하여 무한 문맥 모델에 입력하는 방식이 될 것이다. 이는 RAG의 ‘문맥 파편화’ 문제를 해결하고, 무한 문맥 모델의 ’비용 문제’를 완화하는 중용의 도(道)다.3
• 적응형 문맥 관리 (Adaptive Context Management): MemGPT에서 제안한 바와 같이, 에이전트는 운영체제(OS)가 메모리를 관리하듯 스스로 ‘무엇을 기억하고(Core Memory)’, ‘무엇을 찾아볼지(Retrieval)’, ’무엇을 장기 기억에 저장할지(Archival Memory)’를 동적으로 결정하는 메타 인지 능력을 갖추게 될 것이다.40
• 가상 문맥(Virtual Context): Jamba나 Titans와 같은 모델은 RAG로 검색된 정보를 단순히 참조하는 것을 넘어, 이를 자신의 신경망 파라미터에 실시간으로 통합(In-context Learning/Test-Time Training)하여, 마치 처음부터 그 정보를 알고 있었던 것처럼 행동하는 ’가상 문맥’을 형성하게 될 것이다.

결론적으로, 무한 문맥 기술은 RAG를 폐기하는 것이 아니라, RAG의 차원을 격상시키는 촉매제다. 우리는 **“단순히 검색(Retrieval)하여 베껴 쓰는 에이전트“에서 “정보를 소화하여 기억(Memory)하고 숙고(Reasoning)하는 에이전트”**로 진화하는 과도기에 서 있다. RAG는 이 새로운 지능적 존재의 외부 기억 장치(External Storage)로서, 무한 문맥 모델은 그 정보를 처리하는 중앙 처리 장치(CPU)로서 기능하며, 두 기술은 더욱 긴밀하게 통합되어 ’무한한 지식’과 ’무한한 문맥’을 동시에 다루는 강력한 하이브리드 인텔리전스를 완성해 나갈 것이다.

7. 참고 자료

1. [R] Mamba: Can We Achieve Infinite Context Length? : r/MachineLearning - Reddit, https://www.reddit.com/r/MachineLearning/comments/1it279f/r_mamba_can_we_achieve_infinite_context_length/
2. Mamba Explained - The Gradient, https://thegradient.pub/mamba-explained/
3. RAG vs Long Context Models [Discussion] : r/MachineLearning - Reddit, https://www.reddit.com/r/MachineLearning/comments/1ax6j73/rag_vs_long_context_models_discussion/
4. RAG against the infinite context machine: unit economics is all you need - Chamomile.ai, https://chamomile.ai/rag-vs-full-context/
5. Titans + MIRAS: Helping AI have long-term memory, https://research.google/blog/titans-miras-helping-ai-have-long-term-memory/
6. Jamba: A Hybrid Transformer-Mamba Language Model - arXiv, https://arxiv.org/html/2403.19887v1
7. From Transformer to Mamba - by Manav Gupta - Medium, https://medium.com/@manavg/from-transformer-to-mamba-e2b129e282a8
8. scottsus/jamba-KI · Datasets at Hugging Face, https://huggingface.co/datasets/scottsus/jamba-KI/viewer
9. The Role of Long Context in LLMs for RAG: A Comprehensive Review | by miteigi nemoto, https://medium.com/@miteigi/the-role-of-long-context-in-llms-for-rag-a-comprehensive-review-499d73367e89
10. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - arXiv, https://arxiv.org/html/2312.00752v2
11. What Is A Mamba Model? | IBM, https://www.ibm.com/think/topics/mamba-model
12. An Introduction to the Mamba LLM Architecture: A New Paradigm in Machine Learning, https://www.datacamp.com/tutorial/introduction-to-the-mamba-llm-architecture
13. BIMBA: Selective-Scan Compression for Long-Range Video Question Answering - arXiv, https://arxiv.org/html/2503.09590v2
14. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - OpenReview, https://openreview.net/forum?id=tEYskw1VY2
15. Stuffed Mamba: Oversized States Lead to the Inability to Forget | OpenReview, https://openreview.net/forum?id=CdRauNXD1w
16. Stuffed Mamba: State Collapse and State Capacity of RNN-Based Long-Context Modeling, https://openreview.net/forum?id=cu2CT2VAvs
17. Stuffed Mamba: State Collapse and State Capacity of RNN-Based Long-Context Modeling, https://www.researchgate.net/publication/384811197_Stuffed_Mamba_State_Collapse_and_State_Capacity_of_RNN-Based_Long-Context_Modeling
18. IBM Granite 4.0: Hyper-efficient, High Performance Hybrid Models for Enterprise, https://www.ibm.com/new/announcements/ibm-granite-4-0-hyper-efficient-high-performance-hybrid-models
19. IBM’s Path with Granite 4.0 to Balance Security and Scale - The National CIO Review, https://nationalcioreview.com/articles-insights/extra-bytes/ibms-path-with-granite-4-0-to-balance-security-and-scale/
20. Titans: Learning to Memorize at Test Time - A Breakthrough in Neural Memory Systems, https://www.shaped.ai/blog/titans-learning-to-memorize-at-test-time-a-breakthrough-in-neural-memory-systems
21. BYTEBURST #5 “The Rise of Neural Memory Systems and Test-Time Learning”, https://blog.trukhin.com/byteburst-5-the-rise-of-neural-memory-systems-and-test-time-learning-6035610ac31d
22. Titans: Learning to Memorize at Test Time - arXiv, https://arxiv.org/html/2501.00663v1
23. API Pricing - OpenAI, https://openai.com/api/pricing/
24. LLM Total Cost of Ownership 2025: Build vs Buy Math - Ptolemay, https://www.ptolemay.com/post/llm-total-cost-of-ownership
25. Longer context ≠ better: Why RAG still matters - Elasticsearch Labs, https://www.elastic.co/search-labs/blog/rag-vs-long-context-model-llm
26. The Hidden Cost of “Hello”: Why Every Token in Your LLM Stack Matters | by Rahul Powar, https://rahulpowar.medium.com/the-hidden-cost-of-hello-why-every-token-in-your-llm-stack-matters-762819125946
27. What are the current best models for “needle in a haystack” queries and summarization of long documents? : r/LocalLLaMA - Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1ebvi3e/what_are_the_current_best_models_for_needle_in_a/
28. Reasoning on Multiple Needles In A Haystack - arXiv, https://arxiv.org/html/2504.04150v1
29. Stuffed Mamba: State Collapse and State Capacity of RNN-Based Long-Context Modeling - arXiv, https://arxiv.org/html/2410.07145v1
30. Breaking the Context Window: Building Infinite Memory for AI Agents : r/Rag - Reddit, https://www.reddit.com/r/Rag/comments/1n9680y/breaking_the_context_window_building_infinite/
31. RAG vs. long-context LLMs: A side-by-side comparison - Meilisearch, https://www.meilisearch.com/blog/rag-vs-long-context-llms
32. The Needle in the Haystack Test and How Gemini Pro Solves It | Google Cloud Blog, https://cloud.google.com/blog/products/ai-machine-learning/the-needle-in-the-haystack-test-and-how-gemini-pro-solves-it
33. Jamba: A Hybrid Transformer-Mamba Language Model - arXiv, https://arxiv.org/pdf/2403.19887
34. IBM Granite 4.0 Deep Dive: Hybrid Mamba-Transformer Architecture - Skywork.ai, https://skywork.ai/blog/ibm-granite-4-0-deep-dive-hybrid-mamba-transformer-architecture/
35. BABILong: a long-context needle-in-a-haystack benchmark for LLMs - GitHub, https://github.com/booydar/babilong
36. RAG to Riches - LightOn AI, https://www.lighton.ai/lighton-blogs/rag-to-riches
37. Architectural Evolution in Large Language Models: A Deep Dive into Jamba’s Hybrid Transformer-Mamba Design - Greg Robison, https://gregrobison.medium.com/architectural-evolution-in-large-language-models-a-deep-dive-into-jambas-hybrid-transformer-mamba-c3efa8ca8cae
38. Granite 4.0 - IBM, https://www.ibm.com/granite/docs/models/granite
39. Revolutionizing AI with Jamba: The Cost-Effective Game-Changer for Long Contexts, https://towardsai.net/p/l/revolutionizing-ai-with-jamba-the-cost-effective-game-changer-for-long-contexts
40. memgpt | PDF | Queue (Abstract Data Type) - Scribd, https://www.scribd.com/document/941810065/memgpt
41. MemGPT - Towards LLMs As Operating Systems - 2310.08560 | PDF - Scribd, https://www.scribd.com/document/680726596/MemGPT-Towards-LLMs-as-Operating-Systems-2310-08560